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ABSTRACT 


The  Naval  Air  systems  Command  (NAVAIR)  is  seeking  to 
improve  its  information  resource  management  (IRM)  through  the 
i 3e  of  information  systems  (IS)  architectures.  Although 
several  attempts  have  been  made,  NAVAIR  currently  has  no 
overall  IS  plan.  Enterprise  Architecture  Planning  (EAP)  is  a 
comprehensive  planning  methodology  that  allows  organizations 
to  rapidly  adapt  and  survive  in  dynamic  environments.  The  use 
of  EAP  and  the  tools  and  resources  currently  available  will 
provide  NAVAIR  with  a  strategic  advantage  in  an  era  of 
diminishing  resources.  This  thesis  presents  NAVAIR  with  an 
analysis  of  methodologies  and  tools  which  will  prove  useful  in 
the  development  of  an  overall  information  systems 
architecture . 
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I .  INTRODUCTION 


A.  PROBLEM  STATEMENT 

The  Department  of  Defense  has  received  much  criticism  in 
recent  years  for  the  mismanagement  of  its  information 
resources  and  automated  data  processing.  Previous  practices 
in  the  management  of  information  systems  have  been  quite 
costly.  Business  methods  have  been  developed  on  an  ad  hoc 
basis  resulting  in  numerous  redundant  computer  systems. 
Minimal  standardization  of  data  across  the  DOD  has  reduced 
portability  and  integration  capabilities  of  current 
applications.  The  Department  has  now  shifted  towards  viewing 
information  as  a  valuable  resource,  attempting  to  accurately 
document  and  plan  information  systems,  thereby  insuring  more 
cost  effective,  integrated  systems  are  developed. 

The  Naval  Air  Systems  Command  (NAVAIR)  is  seeking  to 
improve  its  information  resource  management  (IRM)  through  the 
use  of  information  systems  (IS)  architecture.  Although 
several  previous  attempts  have  been  made,  NAVAIR  currently  has 
no  overall  IS  plan.  Without  an  IS  architecture  they  must  make 
reductions  in  resources  and  programs  with  little  grasp  of  what 
aspects  of  their  organization  are  critical  to  its  success.  It 
is  essential  for  NAVAIR  to  have  an  IS  architecture  to  ensure 


1 


budget  decisions  are  made  from  the  most  informed  posture 
possible  and  that  their  reduced  resources  are  managed 
effectively . 

B .  BACKGROUND 

In  October  of  1989,  the  Department  of  Defense  established 

the  Corporate  Information  Management  (CIM)  initiative  in 

response  to  a  Defense  Management  Report  (DMR)  condemning  DOD 

IRM  business  practices.  CIM  has  been  implemented  in  the 

private  sector  and  was  chosen  based  on  its  ability  to  overcome 

problems  similar  to  those  which  have  plagued  the  DOD: 

including  management  structures,  staffing  levels,  and 
entrenched  corporate  policies  and  cultures  that  impeded 
decisionmaking,  frustrated  innovation,  obscured 
accountability  for  success  and  failure,  and  imposed 
excessive  overhead  costs.  [Ref.  1:  p.  15] 

The  objective  of  CIM  is  to  "increase  the  effectiveness  of 

information  management  while  reducing  the  costs  of  information 

management  to  the  Department."  [Ref.  2:  p.  6]  CIM  emphasizes 

interoperability  and  consistency  between  DOD  components 

through  the  use  of  an  open  architecture,  common  data 

definition,  and  standardization  of  information  resources,  all 

of  which  facilitates  the  sharing  of  information. 

The  Department  of  Defense  identified  eight  administrative 
functional  areas  which  have  common  information  requirements 
within  each  service.  Consolidation  of  related  functions  and 
the  elimination  of  unnecessary  management  layers  within  these 


2 


areas  will  increase  their  efficiency  while  lowering  overall 
costs.  [Ref.  1:  p.  16]  The  eight  functional  areas  are: 

•  Civilian  Payroll 

•  Human  Resources 

•  Contract  Payment 

•  Distribution  Center  (or  Warehousing) 

•  Material  Management 

•  Financial  Operations 

•  Medical 

•  Government  Furnished  Materials  [Ref.  3:  p,  3] 

A  Functional  Group  is  assigned  to  each  area  and  is  tasked  with 
developing  an  IS  strategy  that  is  both  unified  and 
standardized  at  the  DOD  level  as  opposed  to  the  individual 
service  or  agency  level. 

Designed  as  the  vision  of  DOD  in  the  year  2000,  CIM  is 
comprised  of  fourteen  guiding  principles.  Several  key 
principles  are: 


•  Information  will  be  managed  through  centralized  control 
and  decentralized  execution. 

•  Proposed  and  existing  business  methods  will  be  subject 
routinely  to  cost-benefit  analysis  which  includes 
benchmarking  against  the  best  public  and  private  sector 
achievement . 

•  Information  systems  performing  the  same  function  must  be 
common  unless  specific  analysis  determines  they  should  be 
unique . 

•  The  computing  and  communications  infrastructure  will  be 
transparent  to  the  information  systems  that  rely  upon  it. 
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•  Common  definitions  and  standards  for  data  will  exist  DOD- 
wide . 

•  Data  will  be  entered  only  once.  [Ref.  4:  p.  3] 

These  principles  apply  to  all  DOD  components  and  must  be 
incorporated  in  existing  IRM  plans  and  adapted  to  fit  each 
particular  mission. 

Interoperability  between  the  armed  forces  is  a  major 
premise  of  CIM,  as  four  different  methods  of  resource 
management  are  merged  into  one.  An  even  greater  task  lies 
within  each  service  as  no  common  IS  plan  exists.  A  division 
of  labor  has  been  established  to  prevent  duplication  of  effort 
but  the  immense  size  of  this  initiative  necessitates  several 
years  for  completion  of  initial  modules. 

The  Department  of  Navy  has  significantly  increased  its 
attention  on  IRM  efforts  in  recent  years,  however  budget  cuts 
have  hampered  these  efforts.  Furthermore,  funds  originally 
designated  for  IRM  departments  have  been  rerouted  to  the  CIM 
initiative.  New  developments  and  modernizations  have  been 
severely  restricted  to  mission  essential  programs.  Moreover, 
the  vast  size  and  the  large  number  of  components  within  the 
DON  make  documentation  and  planning  an  enormous  assignment. 
The  DON  issued  the  Information  Resources  Strategic  Plan  of 
April  1991  as  a  primary  reference  to  assist  Navy  components  in 
defining  their  IRM  requirements.  The  IRSTRATPLAN  is  a  timely 
document  which  clearly  defines  the  IRM  mission  and  scope  as 
set  forth  by  the  DON  and  is  consistent  with  the  CIM 
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initiative.  The  plan  discusses  five  key  issues  which 
delineate  the  DON  overall  IRM  strategy.  These  issues  include: 

•  Information  architecture 

•  Requirements,  planning,  budget,  and  execution 

•  Acquisition  process 

•  Telecommunications  and  computing  infrastructure  and 
supporting  technology 

•  Workforce  development.  [Ref.  5:  p.  iii] 

The  IRSTRATPLAN  provides  guidance  necessary  for  each  DON 
component  to  begin  defining  its  IRM  requirements. 

Information  systems  architecture  methodologies  are 
effective  tools  in  creating  strategic  plans  for  an 
organization.  Some  of  the  methodologies  that  exist  today  to 
assist  in  the  management  of  information  resources  are  Business 
Systems  Planning  (BSP),  Information  Engineering  (IE),  and 
Enterprise  Architecture  Planning  (EAP).  While  there  is  no 
consensus  on  which  methodology  is  the  "best",  the  underlying 
principle  is  the  need  for  a  comprehensive  understanding  of 
the  flow  of  information  within  an  organization  and  how  that 
information  is  utilized,  IS  architecture  provides 
organizations  with  the  ability  to  assess  their  current 
situation  and  develop  strategies  for  meeting  future 
requirements . 
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Information  systems  architecture  is  a  discipline  designed 
to  develop  a  road  map  of  information  requirements  throughout 
an  organization.  Major  components  of  IS  architecture  include: 

•  Data  architecture  -  physical  mappings,  corporate  and  user 
views . 

•  Application  architecture  -  business  process  groupings 
presented  to  the  end-users. 

•  Geographic  architecture  -  maps  the  information 
requirements  for  strategic  locations  within  the 
organization . 

•  Technology  architecture  -  determines  the  technology 
required  to  meet  all  other  architectures.  [Ref,  6:  p.  17] 

Currently  within  DOD  there  exists  a  "multiplicity  of 
unique  information  system  architectures  with  incompatible 
hardware,  software  and  communications  networks."  [Ref.  4:  p. 
18]  The  inability  to  integrate  systems  prohibits  essential 
sharing  of  data  both  within  and  across  the  services.  The  CIM 
initiative  addresses  this  problem  by  mandating  the  use  of  a 
coiTUTion  information  architecture  framework  by  the  services  to 
ensure  standardization.  Furthermore,  it  is  essential  that 
both  CIM  and  non-CIM  systems  are  capable  of  communicating. 

The  purpose  of  this  thesis  is  to  provide  the  Naval  Air 
Systems  Command's  (NAVAIR)  Information  Resources  Management 
(IRM)  Division  (AIR-713)  with  an  analysis  of  methodologies  and 
tools  to  assist  the  division  in  creating  an  information 
systems  architecture.  The  IRM  division  is  responsible  "for 
formulating  policy,  planning,  budgeting,  directing. 
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administering  and  exercising  oversight  of  the  NAVAIR  IRM 
Program,  for  all  non-tactical  information  systems  {ISs}  and 
associated  resources."  [Ref.  7:  p.  1-1]  The  selection  of 
standard  methodologies  and  tools  within  CIM  is  not  expected 
for  at  least  another  year.  NAVAIR  must  select  a  broad 
methodology  which  has  the  ability  to  use  many  different 
techniques  and  tools,  facilitating  easy  adaptation  within  CIM. 
NAVAIR  will  be  setting  its  own  IS  planning  standards  to  be 
promulgated  throughout  its  command  until  the  CIM  standards  are 
compl ete . 


C.  RESEARCH  QUESTIONS 

The  questions  this  thesis  will  address  are  as  follows: 


1.  What  is  NAVAIR' s  current  information  systems  architecture 
plan? 

2.  What  information  systems  efforts  are  currently  being 
developed  within  NAVAIR? 

3.  What  "culture"  exists  in  NAVAIR  to  enhance/deter  the 
implementation  of  a  new  Information  System  Strategy? 

4.  What  methodologies  are  most  effective  in  determining 
information  systems  requirements? 

5.  How  have  lEF  CASE  tools  changed  in  the  last  two  years  and 
do  they  have  the  capability  to  be  integrated  with  other 
CASE  tools? 

6.  Which  methodology  and  tools  will  be  able  to  increase  the 
effectiveness  and  efficiency  of  NAVAIR  by  improving  the 
structures  and  uses  of  information? 

7.  What  are  the  benefits  to  NAVAIR  exist  from  utilizing  the 
methodology  and  tools  selected? 
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Chapter  II  will  provide  an  overview  and  comparison  of 
methodologies  available  for  architectures  within  the 
constraints  set  forth  by  CIM.  The  architectures  discussed  are 
Enterprise  Architecture  Planning  and  Information  Engineering. 

Chapter  III  will  provide  NAVAIR  with  a  baseline 
architecture  from  which  to  begin  their  overall  IS  plan.  A 
baseline  architecture  corresponds  to  the  Business  Modeling 
phase  of  EAP,  discussed  in  Chapter  II.  In  addition,  two 
previous  NAVAIR  architecture  efforts  will  be  analyzed:  NAVAIR 
Division-04  (AIR-04)  Information  Strategy  Plan  (ISP)  and  the 
Component  Information  Management  Plan  (CIMP). 

Chapter  IV  will  evaluate  barriers  to  implementation  of  an 
IS  architecture.  It  will  provide  some  insight  as  to  how  to 
avoid  and  manipulate  such  barriers  as:  approaches  to  planning, 
organizational  culture,  political  climate  and  senior 
management  involvement. 

Chapter  V  will  include  conclusions  and  recommendations  for 
NAVAIR  Information  Resource  Management  division.  Future 
thesis  topics  will  also  be  provided. 

Information  systems  architecture  will  prove  to  be  a 
crucial  tool  for  structuring  and  manipulating  information  in 
the  future.  NAVAIR  needs  an  information  architecture  to 
document  current  systems  and  to  determine  where  they  would 
like  to  be  in  the  years  to  come.  With  more  reductions  in  the 
IRM  budget  expected,  this  thesis  will  provide  critical 
research  for  NAVAIR  with  substantial  savings  of  both  time  and 
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money.  This  thesis  presents  NAVAIR  with  an  analysis  of 
methodologies  and  tools  which  should  prove  useful  in  the 
creation  of  an  overall  information  systems  archtecture. 
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INFORMATION  SYSTEMS  ARCHITECTURE  METHODOLOGIES 


II  . 

A.  THE  NEED  FOR  AN  IS  ARCHITECTURE 

The  need  for  information  systems  architecture  has  gained 
considerable  momentum  in  recent  years.  Rapid  advancements  in 
computer  and  information  technology  have  had  an  enormous 
impact  on  the  organization's  allocation  of  resources  and  more 
importantly  on  the  strategic  goals  of  businesses. 
Furthermore,  "since  the  technology  permits  'distributing' 
large  amounts  of  computing  facilities  in  small  packages  to 
remote  locations,  some  kind  of  structure  (or  architecture)  is 
imperative  because  decentralization  without  structure  is 
chaos."  [Ref.  8:  p.  276]  An  IS  architecture  has  become  an 
essential  requirement  to  the  survival  of  any  organization  in 
today's  information  age. 

There  is  little  consensus  on  the  definition  of,  or 
procedures  used,  in  an  IS  architecture.  As  mentioned  in 
Chapter  I  it  can  be  a  "road  map"  or  a  "high-level  map  of  the 
information  requirements  of  an  organization."  [Ref.  9:  p.  198] 
IS  architecture  can  be  used  as  a  planning  guide  for  "long- 
range  development  but  also  allow  response  to  diverse  short- 
range  information  system  demands."  [Ref.  10:  p.  122]  Each 
interpretation  illustrates  the  importance  of  IS  architecture 
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as  a  tool  for  docxwnenting  and  developing  an  organizations 
strategy  for  the  future. 

Planned  systems  offer  many  potential  benefits  to  an 
organization.  The  containment  and  reduction  of  costs  has 
become  vitally  important  to  organizations  today. 
Architectures  facilitate  reduction  in  data  entry,  increased 
productivity,  and  identification  and  elimination  of  complex 
interfaces  between  incompatible  systems,  all  of  which  reduce 
costs.  The  increase  in  the  timeliness  of  data  and  the  access 
to  shared  data  further  contribute  to  cost  savings  as 
management  is  able  to  make  better  informed  decisions.  [Ref. 
11:  p.  3EAP1-9] 

The  phrase  "potential  benefit"  is  very  significant  in 
systems  planning.  Many  different  IS  architecture 

methodologies  are  on  the  market  today.  While  many 
organizations  have  attempted  IS  planning  few  organizations 
have  succeeded  in  implementing  them.  Many  obstacles  must  be 
overcome  to  effectively  use  any  methodology: 

•  Awareness/Recognition/Acceptance  by  top  management 

•  Commitment  of  resources  (staff  and  funds) 

•  Lack  of  credibility  of  planning  leaders  (IRM/DA) 

•  Finding  the  'best'  methodology;  Inadequate  tools 

•  Educating  DP  people  in  new  technologies 

•  Crises  today  leave  no  time  for  planning  (other  excuses) 

•  Substantial  up-front  cost;  Benefits  difficult  to  measure 
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•  Inaccessible  or  uncooperative  users;  Delegation.  [Ref. 
11:  p.  3EAP2-4] 

Of  those  obstacles  listed  above,  support  from  top  management 
and  the  commitment  of  resources  are  most  critical . 

This  chapter  provides  an  analysis  of  one  methodology  that 
has  emerged  in  the  past  few  years.  Enterprise  Architecture 
Planning  (EAP) .  EAP  has  been  successfully  implemented  in 
Canada  but  is  only  now  gaining  recognition  in  the  U.S.  A 
comparison  and  contrast  of  EAP  with  the  widely  used 
methodology.  Information  Engineering,  will  conclude  the 
chapter . 

B.  ENTERPRISE  ARCHITECTURE  PLANNING 
1.  Overview 

Enterprise  Architecture  Planning  is  "the  process  of 
defining  architectures  for  the  use  of  information  in  support 
of  the  business  and  the  plans  for  implementing  them."  [Ref. 
11:  p.  3EAP1-2]  The  key  word  in  the  above  statement  is 
"defining."  Many  earlier  architectures  attempted  to  design 
structures  for  the  organization  prior  to  defining  the 
organization  itself.  EAP  emphasizes  the  planning  process  from 
the  initial  decision  to  investigate  IS  architectures  through 
to  its  implementation.  The  migration  or  implementation  plan 
is  one  aspect  of  traditional  systems  planning  methodologies 
which  was  rarely  developed,  and  which  resulted  in  many  failed 
architecture  attempts. 
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EAP  is  a  data-driven  approach  rather  than  process- 
driven.  A  strong  knowledge  base  of  the  organization  is  gained 
through  the  functional  business  model  that  is  developed  using 
EAP.  The  data  architecture  should  be  completed  prior  to  the 
applications  architecture  to  allow  data  dependencies  to 
determine  the  overall  plan.  Furthermore,  EAP  allows  for  both 
short-  and  long-term  planning  which  is  critical  to 
establishing  operational  and  strategic  goals  of  an 
organization.  [Ref.  11:  p.  3EAP1-7] 

There  are  many  business  benefits  of  EAP.  Each  of  the 
following  benefits  works  in  conjunction  with  the  potential 
benefits  of  planned  systems  mentioned  earlier: 

•  Perspective  focus  on  strategic  use  of  technology  for 
managing  data  as  an  asset 

•  Standard  vocabulary  facilitates  communication,  reduces 
inconsistency  and  data  redundancy 

•  Documentation  increases  understanding  of  the  business 

•  Process  considers  integration  of  current  systems  with  the 
new 

•  Cost-effective  long-term  solution  considers  rate  of  return 

•  Methodology  facilitates  easier  assessment  of  the  impact  of 
new  systems 

•  Modeling  allows  easier  accommodation  of  dynamic  business 
changes  such  as  acquisitions,  budget  reductions,  lines  of 
business,  etc. 

•  Management  participation  provides  a  business  perspective, 
credibility,  confidence,  and  demystifies  system 
development.  [Ref.  11:  p.  3EAP1-8] 
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Success  is  measured  in  Enterprise  Architecture 


Planning  as:  the  project  was  compl eted .  the  plan  is  being 

implemented ,  and  "the  architectures  are  used  to  guide  the 
development  and  are  maintained  current."  [Ref.  11:  p.  3EAP2-1] 
The  reason  EAP  has  been  successful  is  that  it  is  not  a 
technical  document.  The  focus  is  on  managing  and  planning. 
Furthermore,  the  commitment  and  support  of  management  is 
gained  at  the  outset  and  maintained  throughout  the  process. 
Participation  from  management  and  end-users,  with  an  equal 
representation  of  business  and  systems  personnel,  allows  for 
greater  ownership  of  the  project  and  greater  cooperation.  An 
"acceptable  balance  of  scope/ objectives  vs.  level  of  detail 
vs.  resources  and  time  committed"  also  adds  to  EAP  successes. 
[Ref.  11:  p.  3EAP2-5]  The  organization's  culture  is 
identified  early  and  the  plans  are  developed  to  fit  the 
culture.  A  completed  architecture  that  ignores  corporate 
culture  will  not  be  accepted  and  will  ultimately  fail. 
Intermediate  deliverables  are  distributed  within  the 
organization  to  provide  constant  communication  and  feedback 
and  ensure  ownership  is  continued. 

Throughout  the  phases  of  the  project,  the  80/20  Rule 
must  be  followed,  i.e.  capture  80  percent  of  the  knowledge  and 
information  benefits  with  20  percent  of  the  effort. 
Planning  is  imperfect  and  time  consuming.  The  EAP  methodology 
insists  that  the  best  personnel  be  used.  To  do  this,  the 
"best"  people  must  take  time  away  from  other  tasks  which 
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ensures  productivity  during  each  meeting  resulting  in 
completing  phases  on  schedule. 

2.  Methodology 

The  components  of  Enterprise  Architecture  Planning  are 
managed  in  a  pyramid  formation: 


A  great  deal  of  effort  is  entailed  in  the  top  level,  Planning 
Initiation.  One  premise  of  EAP  is  that  no  methodology  can  be 
successful  without  ensuring  an  effective  and  efficient  Plan. 
The  second  level,  Business  Modeling  and  Current  Systems  & 
Technology,  determines  and  documents  where  the  organization  is 
today.  Once  level  two  is  complete,  level  three, 
architectures,  defines  where  the  organization  wants  to  be  in 
the  future.  Notice  that  data  architecture  is  completed  prior 
to  applications  architecture.  The  final  level, 
Implementation/Migration  Plans,  provides  the  vehicle  for  the 
organization  to  attain  its  goals.  The  order  in  which  each 
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component  is  conducted  is  vitally  important  to  the  success  of 
an  EAP  project  as  each  preceding  component  ensures  a  strong 
knowledge  base  for  the  component  following. 

The  Planning  Initiation  phase  is  comprised  of  seven 

steps : 


1 . 

2. 

3  . 

4  . 

5. 

6. 

7  . 


Determine  Planning  Objectives, 
Suitable  Business  Unit 

Create  a  Vision  (Initial  Meetings 

Adapt  a  Planning  Methodology 

Arrange  for  Computer  Resources 

Assemble  the  Planning  Team 

Prepare  Detailed  Schedule  and 
Workplan) 

Obtain/Confirm  Commitment  and 
Presentations)  [Ref.  11:  p.  3EAP3- 


Scope  and  Select  a 
with  Management) 


Cost  Estimates  (EAP 

Funding  (Executive 

2] 


Defining  the  "enterprise"  is  extremely  important  in 
the  planning  stage.  An  enterprise  may  include  the  entire 
organization,  a  division  or  profit  center,  or  possibly  a 
subsidiary  or  functional  area.  In  selecting  the  business  unit 
for  EAP,  the  following  characteristics  must  be  evaluated: 


FAVORABLE  CHARACTERISTICS 


•  Has  current  strategic  long  range  business  plans 

•  Emphasis  on  quality  improvement  programs 

•  Need  to  integrate  and  share  data 

•  Unsuccessful  DP  projects  or  severe  cost  overruns 

•  Budget  approved  for  major  new  system 

•  Ma^or  business  changes  anticipated 

•  Extensive  management  changes  or  reorganization 
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•  Able  and  willing  to  design  architectures 

UNFAVORABLE  CHARACTERISTICS 

•  Opposites  of  the  above 

•  Shortsighted  management  (time,  budget,  other  excuses) 

•  Recent  "unsuccessful"  planning  attempts 

•  Hostility  or  resentment  towards  systems  people 

•  Uncooperative  "hands-off"  attitude  (delegation) 

•  Experiencing  less  profit,  potential  downsizing 

•  Lack  of  or  disregard  for  standards  or  plans  [Ref.  11:  p. 

3EAP3-5] 

Favorable  characteristics  should  outweigh  unfavorable 
characteristics,  and  a  strategy  should  be  formulated  to 
overcome  potential  obstacles. 

An  adequately  defined  scope  is  crucial  to  a  project  if 
it  is  to  meet  the  needs  of  an  organization.  It  should  include 
all  areas  that  share  data,  or  need  to  share  data.  A  strategy 
is  developed  to  answer  any  unfavorable  characteristics 
identified.  It  is  important  that  the  objectives  are  written 
in  simple,  concise,  nontechnical  language,  focussing  on  the 
benefits  to  the  organization.  The  risk  of  a  too  narrowly 
defined  scope  is  that  the  architecture  will  be  incomplete  and 
independent  causing  integration  probl ems .  Alternately,  if  the 
scope  is  too  broad  the  project  will  have  insufficient  detail 


and  take 

too 

much 

time . 

Any  issues  or  problems 

must 

be 

addressed 

at 

this 

stage 

to  have  complete  confii 

dence 

of 

success  . 

[ Ref  . 

11: 

p.  3EAP3 

-4] 

A 

cri  t 

:ical 

success 

factor  of  this  planning 

phase 

is 

the  need  to  understand  corporate  culture.  While  much 
attention  has  been  given  to  culture  in  recent  years,  there  is 
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little  consensus  on  its  definition.  One  definition  of  culture 


is  : 

a  pattern  of  basic  assumptions-invented ,  discovered,  or 
developed  by  a  given  group  as  it  learns  to  cope  with  its 
problems  of  external  adaptation  and  internal  integration- 
that  has  worked  well  enough  to  be  considered  valid  and, 
therefore,  to  be  taught  to  new  members  as  the  correct  way 
to  perceive,  think,  and  feel  in  relation  to  those 
problems.  [Ref.  12:  p.  9] 

Another  definition  states  that  "the  purpose  of  culture  is  to 
provide  members  with  a  sense  of  identity  and  to  generate  a 
commitment  to  beliefs  and  values  that  are  larger  than 
themselves."  [Ref.  13:  p.  14] 

Understanding  and  documenting  culture  is  quite 
complex.  Corporate  cultures  are  a  reflection  of  their  leaders 
and  without  their  visible  support,  an  architecture  effort  will 
encounter  "a  counter-cultural  effort  to  implement  cooperation 
and  some  centralized  decision  making."  [Ref.  14:  p.  ID/2] 
There  are  several  different  techniques  for  evaluating  cultures 
(Figures  1  and  2).  These  methods  identify  specific 
characteristics  (i.e.  entrepreneurial,  competitive, 
participative)  which  exemplify  the  organization.  Through 
careful  examination  of  an  organization's  culture  an  EAP  plan 
can  be  developed  within  the  constraints  of  the  culture, 
ensuring  critical  commitment  and  cooperation  throughout  the 
organization  is  achieved. 

A  vision  statement  merges  the  project's  scope  with  the 
organizational  culture  to  invoke  enthusiasm  and  support.  It 
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Stages  of  the 
Change  Process 


Elements 


Types  of  Culture 


Entrepreneurial 

Bureaucratic 

Participative 

Organic 


Subjective 

Objective 

Value  Systems*  Ideology 

Behavioral 

Ethical  Premises 

Patterns 

Assumptions  and 

Reward  System 

Beliefs 

Organizational 

Nature  of  Organize- 

Climate 

tional  Reality 

Rules  of  the 

Managerial  Style 

Game 

Organizational 

Norms 

Symbols 

Corporate 

Strategy 

Strategies  for 

Internal 

Integration 

Cultural  Audit 


Culture-Value  Adjustment 
Requirements  of  New  Technologies 


High  Cultural/Value 

Low  Cultural/Value 

Adjustment  Capacity 

Adjustment  Capacity 

1. 

2. 

3. 

4 

5. 

6. 


Normative  Uncertainty  1. 

Martlet  Focus 

Decentralized  Decision-Making  2. 

Distnbuted  Data  Bases  3. 

Information  Sensor  Subsystem  4. 

Activated  5. 


Dynamic  Value  System  and  Symbols 

6. 


Homogeneity  of  Organizational 
Culture 

Internal  Integration  Focus 
Centralized  Decision  Making 
Integrated  Data  Bases 
Information  Control  Subsystem 
Activated 

Static  Value  System  and  Symbols 


Figure  1.  A  Conceptual  Framework  of  Organizational  Cultur 
and  Change  [Ref.  13] 


ENTREPRENEUR I AL 

Risk  Encouraging 
Informa  1 
Decisive 

Results  Oriented 
Aggressive 


CONSERVATIVE 

Risk  Averse 
Formal 
Deliberate 
Process  Oriented 
Defensive 


CLEAR  AUTHORITY  LINES 

Functional  or  Divisional 
Profit  and  Loss  Responsibility 
Hierarchical 


AMPTGUOUS  AUT’IORITY 
Matrix 

Cost  and  Revenue  Centers 
Consensual 


COOPERATIVE 

Team  Oriented 
Col  1 aborative 
Reward  Oriented 
Merit  Based 


COMPETITIVE 

"Macho" 

Individual istic 
Censure- oriented 
Power  Based 


LED 

Long-Term  Goals 
Clear,  Enduring  Mission 
Big  Picture  Oriented 
Creative 


MANAGED 

Short-Term  Objectives 
Mixed  Messages 
Detail  Oriented 
Anal y t i ca 1 


ETHICAL 

Visible  Ethics  and  Policies 

Ethical  Leadership  and 
Supervi Sion 

Internal  Checks  and  Balances 


AMORAL 

Tacit  Acceptance  of 
Unethical  Behavior 
Hiring  for  Cultural  Fit 

No  Attention  to 

Reconciliation  Between 
Systems 


Figure  2. 


Dimensions  of  [Corporate]  Culture  [Ref.  15:  p.  ID/2] 
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depicts  the  target  environment  the  enterprise  is  working 

towards.  The  most  famous  vision  statement  was  delivered  in 

1961  by  President  John  Kennedy:  "’We  will  put  a  man  on  the 

moon,  and  return  him  safely  to  earth,  by  the  end  of  the 

decade.’"  [Ref.  14:  p.  6]  Another  example  would  be  a 

president  of  an  insurance  company  wanting  policy  holders  to 

complete  their  intended  objective  in  a  single  telephone  call. 

A  vision  statement  is  simply  one  that  identifies  the 

organization’s  aspirations  for  the  future. 

A  unique  and  critical  aspect  of  EAP  is  that  other  IS 

methodologies  can  be  incorporated  into  the  project.  Again, 

EAP  is  a  defining  and  planning  process,  and  therefore,  any 

methodology  that  can  assist  in  the  process  is  viable.  The 

following  methodologies  and  teachings  can  be  applied  to  EAP: 

-->  IBM’s  BSP,  BSPI,  and  BSPX 

-->  Books  by  James  Martin  and  Others 

-->  Inf  ormation  Engineering  (JMA,  PIM,  Knowl  edgeware  ,  PDC ) 
-->  SSP  and  TSP  (Holland) 

-->  System  Architecture  (Nolan)  and 

Investment  Strategy  (Norton)  [Ref.  11:  p.  3EAP3-12] 

The  methodology  chosen  should  be  easy  to  understand, 

compatible  with  the  existing  culture/politics,  utilize 

automated  tools,  and  produce  a  long-range  implementation  plan. 

Consultant  firms  trained  in  EAP  are  also  an  option,  but  can  be 

costly  and  time  consuming.  Once  selected,  the  methodology 

must  be  tailored  to  meet  the  needs  of  the  particular 

organization. 
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The  steps  involved  in  the  Planning  Initiation 
component  all  combine  to  win  commitment  from  top  management. 
The  project  is  scoped  and  the  enterprise  selected,  a  vision 
statement  is  promulgated  which  encompasses  the  entire 
organization,  a  methodology  is  adapted,  dedicated  computer 
resources  are  arranged,  a  ski  lied  and  highly  credible  planning 
team  assembl ed ,  and  schedules  and  estimates  prepared,  all  with 
the  expressed  purpose  of  the  executive  presentation( s )  .  This 
IS  a  very  political  process  and  must  be  recognized  as  such. 
Proving  the  need  for  an  EAP ,  or  equivalent  architecturing 
effort,  is  essential.  Themes  should  be  used  which  provide 
ownership  throughout  the  organization  (management, 
programmers,  end-users)  with  phrases  such  as:  "We  must  work 
together  toward  the  same  goal".  The  commitment  gained  in 
Planning  Initiation  must  be  attended  to  and  nurtured 
throughout  the  E.AP  project. 

Once  the  planning  phase  has  been  completed,  commitment 
achieved,  the  EAP  team  shifts  to  level  two;  understanding  and 
documenting  current  organizational  structure  and  business 
functions.  Using  the  toolset  selected  earlier,  new 
organization  charts  are  created  to  include  organization  units, 
reporting  structure,  locations,  as  well  as  business  goals  and 
objectives.  This  can  he  a  very  time  consuming  process  and  the 
team  must  stay  quite  focused.  [Ref.  11:  p.  3EAP4-8] 

Identifying  and  defining  business  functions  seeks 
answers  to  the  question  "What  is  it  that  'We'  do?"  A  function 
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is  "any  set  of  actions  performed  in  the  course  of  conducting 


business"  and  "is  defined  entirely  by  its  subfunctions."  [Ref. 
11:  p.  3EAP4-9]  Functions  should  be  defined  along  functional 
lines  versus  reporting  lines.  Decomposition  of  functions 
continues  "until  the  functions  tend  to  be  single  action 
oriented,  executed  repeatedly  and  have  identifiable  outcomes." 
[Ref.  11:  p.  3EAP4-10]  Enterprise  surveys,  interviews  of 
personnel,  are  an  excellent  source  of  information  for 
identifying  business  functions.  The  functional  business  model 
(FBM)  should  be  compiled  using  the  toolset  chosen,  distributed 
within  the  organization  and  presented  by  a  well  respected  team 
member . 

The  Current  Systems  and  Technology  component  is 
frequently  a  subproject  that  can  begin  prior  to  Planning 
Initiation  and  can  be  conducted  concurrently.  The  Information 
Resource  Catalog  (IRC)  produced  in  this  phase  is  a  valuable 
document  for  the  architecture  components.  The  IRC  entails  the 
following: 

•  Reference  to  All  Information  Resources 

Application  Systems 

Data  (Inputs,  Outputs,  Files/DBs) 

Technology  Platforms 

•  Distribution  of  Information  Resources 

•  Information  Locator  for  Management,  Orientation  for  MIS 
Personnel 

•  Baseline  for  Long  Range  Planning  and  Highlights 
Oppor  tuni 1 1 es 

•  Budgeting  and  Cost  Control  Decisions 
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•  Quick  Success  at  Reasonable  Cost,  Establishes  Credibility 

•  Internal  Use  of  Documentation  Tools  [Ref.  11:  p.  3EAP6-2] 

The  IRC  is  then  distributed  to  the  DPs  and  end-users  and 
becomes  the  baseline  for  the  data  architecture  phase. 

The  third  level  in  the  EAP  pyramid  consists  of  the 
three  architectures.  Each  of  these  conforms  to  traditional 
architectural  procedures  and  guidelines.  First,  the  steps 
involved  in  creating  a  data  architecture  are: 

1.  List  Candidate  Entities 

2.  Define  the  Data  Entities,  Attributes  and  Relationships 

3.  Relate  the  Entities  to  the  Business  Functions 

4.  Distribute  the  Data  Architecture 

An  entity  is  defined  as:  "any  person,  place,  concept,  thing, 
or  event  that  has  meaning  (information)  in  the  context  of  the 
business  ('an  aggregation  of  data  needed  for  a  specific 
purpose')  [Ref.  11:  p.  3EAP7-3]  Once  identified,  entities 
provide  valuable  knowledge  of  the  characteristics  of  data  and 
how  data  relates  within  an  organization.  Entity-relationship 
diagrams  are  helpful  in  this  phase  to  illustrate  both  simple 
and  complex  interrelationships  that  exist  within  the  data 
ar chi tectur e . 

In  relating  entities  to  functions,  toolsets  generate 
matrices  using  the  lowest  level  of  each  function.  A  data 
entity  is  identified  as 
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•  Created 


•  Updated 

•  Referenced 

Only  significant  relationships,  based  on  entity  usage,  should 
be  included  in  the  matrix. 

The  deliverable  for  the  first  component  is  the  Data 
Architecture  Report  (DAR)  which  includes  a  list  of  entity 
names,  complete  entity  definition,  Entity-Relationship 
Diagrams,  Entity  Usage  Matrices,  and  any  Data  Flow  Diagrams. 
An  introduction  provides  a  detailed  explanation  on  how  to 
interpret  the  DAR. 

The  second  architecture  component  is  the  applications 
architecture.  Using  the  DAR,  FBM,  and  the  IRC,  all  possible 
applications  are  listed  and  defined.  Application  definitions 
entai  1  : 

•  brief  purpose 

•  general  description  and  capabilities 

•  business  opportunities  and  benefits  (tangible,  intangible) 
[Ref.  11:  p.  3EAP8-5] 

This  definition  should  focus  on  what  it  does,  independent  of 
technology,  and  not  how  the  application  accomplishes  its 
tasks . 

Matrices  are  again  utilized  to  illustrate 
relationships  between  applications  and  business  functions  and 
organizational  units.  The  matrices  depict  the  support  status 
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of  the  applications:  current,  modify,  replace,  planned, 

needed.  Furthermore,  an  Impact  Analysis  is  conducted  to 
determine  if  existing  applications  are  to  be: 

•  completely  replaced 

•  partially  replaced  and  modified 

•  retained  with  minimal  enhancement 

The  last  phase,  technology  architecture,  begins  with 
designing  the  data/applications  distribution  architecture.  In 
this  step,  business  locations  are  associated  with  data  and 
applications  architectures;  traffic  volumes  are  estimated. 
Next,  the  technology  platforms  (layers)  are  defined.  The 
technology  configuration  (i.e.,  hardware,  software,  networks, 
communications)  is  selected  and  costs  estimated.  Diagramming 
the  configuration  is  helpful  in  formulating  a  vision  of  how 
the  application  and  data  relate  to  the  technology  chosen. 
Estimates  of  the  resources  required  are  also  needed  to  assess 
the  viability  of  the  technology; 

•  people  (number  S  types),  organizational  units  and 
structure 

•  business  impact ,  procedural  changes 

•  policies  and  standards 

•  acquisition  and  capital  expenditures  [Ref.  ll:p.  3EAP9-4] 

The  final  step  of  the  technology  architecture  is  to 
confirm  applications  and  technology.  At  this  stage,  the 
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purpose,  inputs  and  outputs  for  each  application  are  reviewed 
and  any  changes  to  the  FBM  noted.  A  description  of  the 
"technology  'vision'"  is  essential  in  illustrating  the 
benefits  and  opportunities  that  will  be  available  with 
implementation  of  the  architecture.  [Ref.  ll:p.  3EAP9-7] 

While  each  component  resembles  traditional 
architectures,  attributes  exist  that  are  unique  to  EAR. 
Throughout  this  level,  team  interaction  and  discussion  is 
significant  and  essential.  The  team  composition  of  both 
systems  and  business  personnel  guarantees  the  documents  will 
be  comprehensive  and  easy  to  read.  Creativity,  inventiveness, 
and  the  use  of  team  brainstorming  are  effective  skills 
utilized  in  each  phase.  Furthermore,  the  team  must  determine 
how  they  define  "consensus"  as  EAP  requires  it  on  the 
definitions  cf  entities  and  applications.  As  mentioned 
earlier,  communication  both  within  the  team  and  throughout  the 
organization  is  important  to  gain  feedback,  to  confirm  that 
the  project  is  meeting  the  needs  expressed  in  the  planning 
phase,  and  to  maintain  commitment  from  top  management  and  the 
organi zation . 

The  final  stage  of  the  EAP  process  is  the  phase  most 
neglected  by  other  IS  architecture  methodologies.  The 
Implementation/Migration  Plans  component  is  what  distinguishes 
EAP  most  from  other  methodologies.  This  component  is 
comprised  of  three  phases:  Data  Development  Plan,  Planning 
Conciusicr. ,  and  Transition  to  Implementation. 
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The  Data  Development  Plan  sequences  and  prioritizes 
the  applications  and  estimates  the  effort,  resources, 
schedules,  costs,  and  benefits.  Critical  success  factors 
(CSF)  are  determined  and  recommendations  (desired  management 
decisions)  are  made  in  this  particular  phase.  The  CSFs  "are 
conditions  that  will  contribute  to  or  enable  the 
implementation  of  the  plan  to  proceed  toward  a  successful 
conclusion  which  are  either  not  presently  in  place  or  are  in 
jeopardy  of  an  unfavorable  change."  [Ref.  11:  p.  3EAP10-15] 
Some  common  CSFs  are: 

•  Immediate  initiation  of  the  Transition  Phase 

•  Approval  of  plan  (with  initial  projects) 

•  Adopting  new  system  development  methods  (I.E.,  0-0) 

•  Eval uation/Sel ection/Acquisition/ Instal 1 ation  of 

-  hardware  platforms  (network,  connectivity) 

-  software  packages 

-  CASE 

•  Standards  and  Procedures 

•  Approval  of  budget 

•  Reorganizing  I . S . ;  Shifting  responsibi 1 ities [Ref .  11: 

p.  3EAP10-16] 

Training  requirements  for  each  phase  of  implementation  are 
also  determined,  to  include  DP  department  personnel  and 
applications  and  technology  end-users. 

The  second  phase  of  implementation  is  Planning 
Conclusion.  The  final  EAP  report  is  prepared  and  must  be 
consistent  with  the  corporate  culture.  Strong,  emotional 
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wording,  unsubstantiated  statements,  unlabeled  opinions,  and 
controversial  subjects  should  be  omitted  from  the  report. 
[Ref.  11:  p.  3EAP11-4]  Presentations  are  prepared  and 
delivered  to  management  "to  explain  the  results  of  EAP  and  the 
plans,  and  ultimately  to  obtain  their  approval  or  support  to 
proceed  with  the  implementation."  [Ref.  11:  p.  3EAP11-6] 
Presentations  are  also  made  to  every  department  within  the 
enterprise . 

The  final  phase  of  the  entire  EAP  project  is 
Transition  to  Implementation.  There  are  eleven  steps  to  be 
compl eted : 


1.  Plan  the  Transition 

2.  Adopt  a  System  Development  Approach 

3.  Arrange  for  Computer  Resources 

4.  Refine  the  Architectures 

5.  Institute  Organizational  Changes 

6.  Recruit  Irr.p  1  ement at i on  Personnel 

7.  Provide  Thorough  Training 

8.  Establish  Programming  Standards 

9.  Establish  Procedural  Standards 

10.  Develop  a  Detailed  Workplans  for  the  First  Group  of 
App 1 1  cat i ons 

11.  Confirm  the  End  of  Transition  [Ref.  11:  p.  3EAP12-2] 


Evident  by  this  extensive  list  of  steps  is  the 
comprehensiveness  and  attentiveness  of  EAP  to  validate  the 
implementation  process  and  guarantee  success.  A  transition 
phase  workplan  is  developed  to  address  and  schedule  the  above 
steps,  as  well  as:  plan  for  the  acquisition  and  installation 
of  hardware  and  software,  develop  a  strategy  for  managing 
political  obstacles,  determine  approaches  to  and  projects  for 
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prototyping,  and  schedule  the  recruiting  and  training  of 
personnel.  The  workplan  is  a  thorough  attempt  to  confirm  that 
all  avenues  and  obstacles  have  been  examined  prior  to 
implementation . 

Essential  throughout  the  EAP  process,  and  specifically 
during  the  transition  phase,  is  the  need  to  maintain  high 
enthusiasm  and  momentum  for  both  the  team  members  and  the 
organization.  Steady  progress  is  imperative.  Resistance  to 
change  can  retard,  if  not  destroy,  an  implementation  plan  and, 
therefore,  must  be  effectively  managed.  The  transition  phase 
requires  strong  leadership  and  direction  to  allow 
implementation  to  proceed. 

3.  Assessment  of  EAP 

Enterprise  Architecture  Planning  is  a  thorough 
methodology  for  information  systems  planning.  From  the 
selection  of  team  members,  to  the  care  and  attention  given  to 
each  step  of  each  component,  EAP  is  exhaustive  in  its  efforts. 
Costly,  redundant  systems  are  identified  and  eliminated. 
Applications  are  developed  quicker  and  along  functional  lines, 
increasing  productivity  and  improving  user  skills.  Critical 
management  decisions  are  based  on  more  accurate  and  timely 
data,  effecting  a  more  stable,  cost-efficient  organization. 

EAP  is  an  objective  and  impartial  approach  to  IS 
architectures.  Organizational  participation  allows  everyone 
to  take  ownership  of  the  effort.  The  continuous  communication 
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and  distribution  of  intermediate  deliverables  provides 
constructive  feedback  to  verify  the  project  is  meeting  the 
needs  of  the  organization.  A  viable  migration  strategy  is 
developed  for  both  long  and  short  term  plans  to  effect  smooth 
implementation.  The  flexibility  of  EAP  allows  organizations 
to  rapidly  adapt  to  and  survive  in  dynamic  environments. 

C .  I NFORKAT I ON  ENG I NEER I NG 
1.  Overview 

Information  engineering  (IE)  is  a  widely  recognized 
methodology  in  the  field  of  Information  Systems.  Information 
engineering  "refers  to  the  set  of  interrelated  disciplines 
that  are  needed  to  build  a  computerized  enterprise  based  on 
information  systems."  [Ref.  17:  p.  24]  As  a  data-driven 
approach,  IE  has  traditionally  confined  itself  to  data  and 
data  architecture.  Other  characteristics  of  IE  include: 

•  It  is  driven  by  the  user. 

•  It  anchors  data  processing  expenditure  in  top  management's 
needs  and  goals. 

•  It  identifies  how  computing  can  best  aid  the  strategic 
goals  of  management. 

•  It  is  based  on  easy- to-understand  diagrams. 

•  It  employs  a  steadily  evolving  central  repository  of 
knowledge  about  the  enterprise. 

•  It  uses  CASE  tools  to  link  diagrams  with  code  generators 
and  f our th- general 1  on  languages. 


•  It  uses  prototypes. 

•  It  assists  information  center  activities. 

•  It  is  integrated  throughout  the  information  systems 
function . 

•  Its  goal  is  full  automation  of  the  database  and 
application  development  process.  [Ref.  17:  p.  24] 

Information  engineering  merges  the  talents  of  users, 
management  and  DP  personnel  in  an  effort  to  "identify, 
implement  and  process  the  data  that  supported  the  business." 
[Ref.  16:  p.  11]  Users  and  managers  are  now  able  to  complete 
much  of  the  design  requirements  resulting  in  more  complete 
specifications  which  reduces  the  time  required  for  application 
development,  thereby  reducing  the  application  backlog. 

There  are  several  different  versions  of  information 
engineering  currently  on  the  market.  One  interpretation  by 
Clive  Finkelstein  provides  extensive  integ -ation  of  CASE  tools 
throughout  the  IE  process.  The  data  modeling  components  of 
this  version  of  IE  closely  coincides  with  the  architecture 
requirements  of  NAVAIR.  The  information  engineering 

methodology  discussed  in  the  next  section  is  strictly  that  of 
Clive  Finkelstein. 

2.  Methodology 

Beginning  in  1976,  IE's  primary  focus  was  on  data  base 
design.  Several  years  later  it  incorporated  such  techniques 
as  data  and  information  analysis  and  information  systems 
design.  Currently,  information  engineering  has  evolved  to 
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include  strategic,  tactical  and  operational  data  modeling. 
But  the  focus  has  not  shifted  from  data.  IE's  Data  Modeling 
identifies  and  defines  entities  and  produces  Entity 
Relationship  Diagrams.  However,  IE  extends  that  process  to 
include  data  mapping  which  resembles  the  normalization  process 
used  in  Data  Base  Management  Systems  (DBMS).  The  purpose  of 
the  normalization  process  is: 

The  application  of  a  formal  set  of  rules  which  determine 
those  key  attributes  which  uniquely  identify  each  data 
attribute,  and  which  place  each  attribute  in  an  entity 
where  it  is  fully  identified  by  the  whole  primary  key  of 
that  entity.  [Ref.  16:  p.  94] 

The  data  modeling  process  is  extensive  in  the  effort  to 
capture  all  data  utilized  by  an  organization. 

There  is  a  significant  emphasis  placed  on  strategic 
and  tactical  planning  by  IE.  Strategic  management  is 
accomplished  through  "communication,  execution  and  management 
of  strategic  planning"  which  leads  to  successful  strategic 
imipl  ementation .  [Ref.  16:  p.  158]  Two  main  types  of  strategic 
planning  exist:  corporate  and  systems.  Corporate  planning  is 
attended  to  by  top  management  while  systems  planning  has  been 
a  function  of  DP  departments.  To  align  these  two,  systems 
planning  should  be  incorporated  into  the  corporate  planning 
department . 

Several  problems  which  arose  from  traditional 
strategic  planning  are:  [Ref.  16;  p.  160] 
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Strategic  Planning 

Limited  strategic  alternatives 

1 

Strategic  Implementation 

Ineffective  communication 
Misinterpretation 

Strategic  Management 

Long  feedback  cycle  (3-5  years) 
Ineffective  performance 
monitoring 

strategic  planning  in  information  engineering  can  be 
accomplished  using  either  a  formal  or  informal  approach. 
Although  the  processes  are  somewhat  different,  both  approaches 
result  in  a  strategic  statement  which  entails: 

•  Mission  and  purpose. 

•  Concerns  and  issues. 

•  Goals  and  objectives. 

•  Policies. 

•  Strategies  and  tactics.  [Ref.  16:  p.  175] 

The  informal  planning  approach  also  includes  tactical 
statem.ents  which  define  the  objectives  and  procedures  that 
will  assist  the  organization  in  rapidly  adapting  to  changes  in 
their  environment. 

Information  engineering  has  three  primary  phases: 
Analysis  Phase,  Design  Phase  and  Generatior',  Phase.  During  the 
analysis  phase,  data  and  inf ormativ./n  required  at  the  strategic 
and  tactical  management  levels  are  defined  using  the  strategic 
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and  tactical  statements  developed  prior  to  the  start  of  the 
project.  The  steps  involved  in  this  phase  are: 

1.  Project  scope 

2.  Strategic  modeling 

3.  Tactical  modeling 

4.  Operations  modeling 

The  strategic  model  focuses  on  high-level,  senior  management 
issues  with  long-term  goals,  while  the  tactical  model 
represents  middle  management  interests  and  short-term 
objectives.  An  operations  model  concentrates  on  the  day-to 
day  operations  and  objectives  of  an  organization. 

The  users  are  primarily  responsible  for  the  analysis 
phase.  IE  techniques  and  expert  systems  are  employed  to 
capture  the  users  expert  knowledge.  The  effect  of  this  phase 
is  "the  progressive  definition  of  the  data  resource."  [Ref. 
16:  p.  229]  The  data  is  then  examined  in  the  design  phase  to 
identify  common  and  redundant  data,  and  is  mapped  to  users  and 
functions  within  an  enterprise.  It  is  recommended  that  the 
analysis  and  design  phase  be  conducted  concurrently  to 
increase  productivity. 

The  design  phase  is  automated  using  expert  design 
tools.  An  exper'  .ctionary  is  used  to  check  the  consistency 
and  accuracy  of  data  definitions  used  by  all  three  models. 

data  i -•  '^ombined  into  integrated  strategic,  tactical 
and  operations  models,  and  become  inputs  to  the  final  phase. 
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The  generation  phase  defines  implementation  strategies 
appropriate  to  each  part  of  the  integrated  strategic  and 
tactical  models.  It  determines  the  hardware,  software 
and  communication  facilities,  and  the  physical  design  and 
development  of  defined  information  systems  and  expert 
business  systems.  [Ref.  16:  p.  231] 

Conventional  files,  DBMS  products,  3GLs  and  4GLs ,  or  expert 
systems  may  be  used  to  represent  the  data  in  the  applications 
development  process.  This  phase  defines  the  physical 
implementation  of  data,  systems  and  reports. 

3.  Assessment  of  Information  Engineering 

Information  engineering  results  in  the  construction  of 
a  data  architecture.  Data  that  is  vital  to  the  enterprise  and 
the  decision  making  process  is  identified  and  documented.  IE 
is  "objectives  driven"  in  that  goals  and  objectives  are  set 
forth  for  all  levels  of  the  organization.  Also,  as  a  user 
dr i ven methodol ogy  ,  inf ormation  engineering  extracts  essential 
knowledge  to  confirm  that  applications  meet  the  users'  needs. 

Information  engineering  is  an  evolutionary  process 
with  data  being  constantly  elaborated  and  enhanced,  as  well  as 
consolidated  when  redundancy  is  evident.  Furthermore,  IE 
provides  rapid  feedback  from  management  on  strategic 
alternatives  through  the  use  of  what-if  scenarios.  As  a 
highly  automated  methodology,  IE  relies  upon  data 
dictionaries,  data  bases  and  knowledge  bases  which  are  updated 
automatically  affecting  consistency  and  integration  of  models. 
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D.  COMPARISON  OF  ENTERPRISE  ARCHITECTURE  PLANNING  AND 


INFORMATION  ENGINEERING 

Enterprise  Architecture  Planning  and  Information 
engineering  are  both  data-driven  approaches.  EAP  is  a 
planning  methodology  whereas  IE  is  a  highly  developmental 
methodology.  The  strategic  planning  conducted  in  IE  occurs 
prior  to  the  official  start  of  the  project.  Planning  within 
EAP  is  conscious  and  deliberate  from  the  beginning  through 
implementation.  Moreover,  the  structure  of  each  methodology 
is  quite  different.  EAP  incorporates  three  levels  comprising 
seven  phases  in  its  methodology  whereas  IE  has  only  three 
phases.  The  few  corollaries  that  can  be  drawn  between  EAP  and 
IE  primarily  correspond  to  the  data  modeling  phase. 

The  most  significant  benefit  of  information  engineering  is 
the  development  of,  in  EAP  terms,  a  data  architecture. 
However,  IE  fails  to  adequately  satisfy  the  application  and 
technology  architecture  needs  of  an  organization.  The 
combination  of  the  three  architectures  is  important  for 
mapping  current  data  to  future  requirements.  The 
architectures  also  provide  the  necessary  documentation  of 
shared  data,  thereby  creating  systems  and  applications  which 
support  the  organization.  IE  also  does  not  address  the 
implementation  phase  to  the  degree  EAP  does.  The 
implementation  plan  seeks  to  identify  all  potential  obstacles, 
set  milestones,  and  is  structured  to  maintain  organizational 


37 


commitment.  This  phase  is  essential  to  the  success  of  an  IS 
architecture . 

Enterprise  Architecture  Planning  is  an  extensive  and 
exhaustive  methodology  with  the  primary  objective  of 
implementing  a  project.  The  attentiveness  to  planning  as  an 
integral  part  of  the  whole  project  sets  this  methodology  apart 
from  all  others.  The  ability  to  integrate  other  methodologies 
adds  flexibility  and  credibility.  Information  engineering  can 
be  an  excellent  tool  within  Enterprise  Architecture  Planning, 
but  as  a  stand  alone  methodology,  it  lacks  the  comprehensive 
characteristics  and  components  of  EAP . 

To  support  NAVAIR  in  incorporating  EAP  principles  in  their 
architecture  effort,  a  baseline  architecture  is  proposed  in 
the  following  chapter. 
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Ill . 


A  BASELINE  ARCHITECTURE  FOR  NAVAIR 


A.  PREVIOUS  ARCHITECTURE  EFFORTS 
1.  AIR-04  ISP 

The  Aviation  Logistics  department  of  the  Naval  Air 
Systems  Command  published  the  AIR-04  Information  Strategy  Plan 
(ISP)  in  March  of  1989.  The  ISP  was  based  largely  upon  a 
combination  of  IE  methodologies.  Although  the  effort  devoted 
to  this  plan  was  extensive,  it  was  not  successful  by  EAP 
standards,  since  it  was  not  implemented.  The  most  significant 
problem  which  affected  every  aspect  of  the  project  was  the 
lack  of  a  clear  and  concise  scope  which  had  the  consensus  of 
the  participating  team  members,  [Ref.  17:  p.  9] 

The  overall  scope  of  this  project  was  established  by 
departmen*  ,  AIR-04,  and  not  by  functional  areas  within  NAVAIR. 
This  resulted  in  an  inability  to  adequately  document  areas 
outside  of  AIK-04.  Furthermore,  the  functional  areas  chosen 
by  the  ISP  team  members  were  along  the  following  departmental 
versus  functional  lines:  Administrative  Support,  Policy  and 
Planning,  Property  Management,  Program  Management ,  Operations 
Support,  Financial  Management.  The  AIR-04  ISP  failed  to 
define  and  document  the  information  flows  in  sufficient 
detail,  ar  well  as  how  information  is  shared,  and  therefore. 
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could  not  be  effectively  implemented  within  the  Aviation 
Logistics  department  or  NAVAIR.  [Ref.  17:  p.  33] 

2.  NAVAIR  GIMP 

The  Component  Information  Management  Plan  (GIMP), 
promulgated  annually,  sets  forth  NAVAIR's  policy  for 
information  resources/information  systems  (IR/IS)  support. 
The  GIMP  "reflects  a  critical  analysis  of  IR/IS  requirements 
and  priorities"  [Ref.  18:  Foreword]  and  GIMP  incorporates  the 
Information  Requirement  Plans  (IRP)  which  are  divided  into 
seven  functional  areas: 

•  Logistics 

•  Systems  and  Engineering 

•  Contracts,  Administration  and  Business 

•  Financial  Management  Systems 

•  Local  Area  Networks 

•  Local  OA/AIS  Systems 

•  Support  Systems 

Within  each  functional  area  are  the  listings  of  all 
information  systems  which  support  the  various  NAVAIR 
information  requirements.  The  IRP  provides  substantial  detail 
on  the  information  requirements,  management,  resource  support, 
architecture,  and  resource  requirements  (budget)  of  each 
system . 
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while  the  CIMP  is  partitioned  initially  by  functional 
areas,  the  information  systems  within  eauh  aiea  are  net. 
Furthermore,  no  mission  statement  or  executive  overview  is 
provided  as  justification  or  support  for  the  functional  area. 
The  attention  given  to  individual  systems  needs  to  be  extended 
to  the  functional  areas  to  ensure  cohesiveness  and  validity  of 
existing  systems. 

B.  A  BASELINE  ARCHITECTURE 

The  AIR-04  ISP  and  the  CIMP  contribute  valuable 
information  and  lessons  learned  to  begi,;  ...  baseline 
architecture.  This  effort  is  not  intended  to  be  comprehensive 
but  rather  a  starting  point,  implementing  EAP  techniques,  to 
assist  NAVAIR  in  identifying  key  steps  in  developing  an 
overall  IS  architecture.  The  baseline  architecture  coincides 
with  the  Functional  Business  Model  (FBM)  discussed  in  Chapter 
II,  and  focuses  only  on  the  Logistics  functional  area. 

Beginning  with  the  deficiencies  noted  in  Section  A, 
functional  areas  must  be  defined  by  what  NAVAIR  does.  The 
functional  areas  designated  by  the  CIMP  are  sufficient  for 
this  purpose  (Figure  3).  To  determine  the  functional  areas 
that  exist  within  Logistics,  a  comparison  of  the  information 
systems  is  required.  Twenty  systems  are  currently  supported 
by  Logistics  (Figures  4  and  5).  The  highlighted  words  in 
Figure  5  denote  common  characteristics  of  these  functions/ 
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Flgur*  3.  MXVAIK  runotlonal  Areas  [Ref.  IB] 
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SYSTEM 
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.Kviation  Training  Support  Systea  - 

Pnase  !I 

ATSS  II 

fleet  replacement  squadron  training, 
support  systems 

Aviation  S-.H  System 

AV-3M 

■aintenance  and  logistics  management 

Airborne  Weapons  Analysis  and  Reporting 
Systei 

AWAP.S 

airborne  neapons 

Airborne  Weapons  Inrormation  System 
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airborne  leapons 

Conventional  Amiunition  Integrated 
Management  System 
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leapoDS 

LOGMARS 

material  movement 

Management  Action  Reporting  System 
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Retail  an:  Reporting 

MEASURE 
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AIS 
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Rapid  Acquisition  of  Manutacturing 
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RAM? 

manufacture  and  support  teapons  systems 

Support  Eguipmient  Resources  Managenent 
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SERMIS 

aviation  support,  maintenance 

Supply  Department  Indormation  System 

SUDIS 

supply  support  for  Point  Mugu,  material 
support 

Uniterm.  Automated  Data  Processing 

System, 

OADPS 

automated  N5F  financial  supply 

Workload  Control  System 

KCE 

liDEP  IS;  NIMHS.  HIFMS.  ASK.ARS 

Worr,-in-Progress  Inven'try  Control 

System 
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Figure  5;  Logistics  Information  Systems  [Ref.  18] 
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systems.  Compiling  like  systems  results  in  five  functional 
areas:  Maintenance,  Material /Suppl y ,  NADEP  ( NAVAVNDEPOT ) , 
Training,  and  Weapons  (Figure  6). 

In  reviewing  Figure  6,  several  factors  become  evident. 
First,  many  of  the  functional  areas  have  numerous  systems 
which  indicates  possible  redundancy.  Furthermore,  within  each 
area,  there  is  at  least  one  major  information  system  which  may 
be  able  to  subsume  some  or  all  of  the  smaller  systems.  For 
example,  the  Naval  Aviation  Depot  has  five  information 
systems,  each  using  some  data  from  the  others.  The  Naval 
Aviation  Depot  Information  Management  (NADIM)  seems  to  be  a 
comprehensive  system  which  may  be  able  to  incorporate  others 
and  thus  reduce  redundancy.  One  peculiarity  arises  in  the 
Material /Suppl y  functional  area;  SUDIS  is  unique  system 
designed  specifically  for  Point  Mugu.  It  may  be  possible  for 
that  system  to  be  subsumed  by  a  larger  IS  or  within  another 
functional  area,  or  based  upon  its  "unique"  contribution  to 
that  functional  area,  remain  unchanged. 

Another  factor  is  that  within  most  of  the  functional 
areas,  functional  decomposition  can  be  continued  facilitating 
further  consolidation  or  identification  of  redundancy.  Within 
the  Weapons  area,  three  subfunctions  are  ident i f iabl e  by  their 
single  action  orientation  (Figure  7).  Finally,  several 
system, s  can  be  assigned  to  more  than  one  functional  area. 
This  IS  acceptable  as  long  as  the  information  flows  are 
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Figure  «.  Logistics  Functions!  Areas  (NEW)  [Ref.  18] 
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correctly  identified,  documented,  and  any  redundancy 
el iminated . 

Upon  analysis  of  the  budget  sheets  provided  for  each 
information  system,  it  is  evident  that  NAVAIR  is  consolidating 
systems  within  functional  areas  (Figure  8).  Again  using 
Weapons,  individual  budget  sheets  for  AWARS  and  MARS  indicated 
that  these  I3s  cease  to  exist  as  standalones  in  FY91  and 
become  applications  of  AWIS.  Another  IS,  CADMSS,  is  also 
integrated  into  AWIS.  however,  a  description  is  not  provided 
in  the  CIM?.  The  budget  implications  for  functional  areas  are 
best  identified  if  budget  sheets  are  consolidated.  The  sheet 
for  Weapons  gives  valuable  insight  into  the  allocation  and 
appropriation  of  funds  and  where  consolidation  of  resources 
may  be  beneficial. 

As  mentioned  with  regard  to  the  AIR-04  ISP,  true 
functional  areas  cannot  be  sufficiently  determined  without 
evaluating  NAVAIR  as  a  whole.  Many  of  these  systems  are  used 
by  other  departments  and  functional  areas.  The  entire 
organization  must  be  taken  into  consideration  to  attain  a  true 
picture  of  how  information  is  utilized  within  NAVAIR. 
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Figure  8:  Weapons  Budget  Sheet 
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IV. 


OVERCOMING  BARRIERS  TO  IMPLEMENTATION 


Numerous  information  systems  architectures  have  been 
attempted  by  civilian  and  government  organizations.  However, 
few  IS  architectures  have  been  implemented  and  utilized. 
Internal  and  external  environments  affect  every  stage  of  the 
planning  process.  These  environments  can  create  barriers  to 
im.plementation  and  must  be  managed  throughout  the  entire 
effort  . 

NAVAIR  faces  four  barriers  to  successful  implementation  of 
their  architecture. 


1.  Inconsistencies  in  approaches  to  planning  profoundly 
affect  the  portability  of  applications  and  the  capability 
to  integrate  systems.  Planning  must  be  initiated  at  a 
level  that  ensures  information  systems  evolve  according 
to  the  needs  of  the  enterprise. 

2.  Misinterpretation  of  organizational  culture  can  lead  to 
extreme  opposition  to  an  IS  effort.  The  culture 
determines  how  best  to  present  and  attain  support  for  the 
project  . 

3.  Fluctuations  in  political  climate,  primarily  within  DOD , 
have  a  direct  impact  upon  the  priority  an  IS  architecture 
receives.  The  internal  and  external  environments  must  be 
stable  and  well  managed  to  guarantee  consistent  backing. 

4.  Inadequate  senior  management  involvement  will  reduce  the 
effectiveness  and  efficiency  of  information  systems.  The 
effort  must  have  substantial  organizational  importance  to 
secure  commitment  and  support  from  all  members  of  the 
organization. 
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These  barriers  can  seriously  impede  the  progress  of  a  project, 
resulting  in  an  ineffective  effort  and  even  failure  of  a 
project. 

A.  APPROACHES  TO  PLANNING 

Planning  must  be  initiated  at  a  level  that  ensures 
information  systems  evolve  according  to  the  needs  of  the 
enterprise.  If  the  approach  is  too  localized  or  departmental 
it  will  lack  connectivity  to  the  overall  organizational  plan. 
Conversely,  if  the  approach  is  too  broad,  the  architecture  may 
lack  sufficient  detail  to  develop  operational  information 
s  y  s  t  ems . 

The  two  approaches  to  business  planning  are  bottom-up  and 
tcp-cown.  Bottorr.-up  planning,  the  most  commonly  used,  is 
conducted  at  the  departmental  level  and  is  primarily  concerned 
with  preserving  budgets  rather  than  addressing  business 
functions.  This  approach  often  creates  plans  which  are 
independent  of  other  activities  within  the  organization 
resulting  in  non-standard,  non-int egrabl e  systems  that  rarely 
meet  or  comply  with  organizational  strategies. 

The  second  approach,  top-down,  dictates  that  planning  is 
initiated  at  the  top  through  a  collaborative  effort  between 
senior  management  and  functional  managers.  Greater  commitment 
from;  subordinates  is  gained  through  this  process. 
Fur  chermiore ,  consistency  with  overall  goals  and  objectives  is 
main" ainec  .  However,  top-down  planning  may  inadvertently  omit 
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vital  information  known  only  by  users  deep  within  the 
organization . 

To  prevent  planning  from  becoming  an  implementation 
barrier,  the  best  approach  is  a  combination  of  the  two. 
Direction  and  strategic  guidance  are  provided  at  the  top, 
while  detailed  planning  formulation  and  implementation  is 
conducted  deep  within  the  organization.  Senior  management 
monitors  and  reviews  plans  to  ensure  congruity  and 
cohesiveness  for  effective  implementation. 

Functional  managers  are  critical  to  the  planning  process 
in  that  they  are  best  able  to  identify  their  detailed  IS 
requirements  and  help  correlate  or  translate  them  into  the 
overall  plan.  Furthermore,  functional  managers  must  be  able 
to  justify  how  their  current  or  future  systems  impact  the 
organ!  sat  i  on ' .s  mission.  For  example,  if  a  functional  area 
within  NAVAIR  requires  a  new  material  management  IS,  its 
impact  on  the  organization's  overall  mission  and  other  ISs 
must  be  explicitly  defined  to  top  management.  The  impact 
statement  should  include  the  drastic  reduction  in  the  location 
and  dispatch  time  required  for  aviation  parts  and  the  benefits 
of  the  elimination  of  two  information  systems. 

The  IS  architecture  team  must  effectively  illustrate  the 
value  of  this  planning  approach  to  obtain  the  organization's 
endorsem.ent  and  to  guarantee  the  process  is  valuable.  The 
effect  of  systems  that  are  inconsistent  with,  or  that  have 
little  relevance  to,  the  organization's  overall  mission 
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(whether  imprudent,  redundant,  or  non-integrabl e)  must  be  made 
clear  by  the  team. 

B.  ORGANIZATIONAL  CULTURE 

The  disregard,  or  inaccurate  identification,  of  corporate 
culture  will  result  in  serious  resistance  to  implementation. 
As  discussed  in  chapter  two,  "the  purpose  of  culture  is  to 
provide  members  with  a  sense  of  identity  and  to  generate  a 
commitment  to  beliefs  and  values  that  are  larger  than 
themselves."  [Ref.  13:  p.  14]  These  beliefs  and  values  can 
blind  management  to  the  significance  of  changing  their 
environment  as  well  as  inhibit  change  if  management  considers 
their  present  practices  successful. 

Changing  corporate  culture  is  a  very  complex  and  delicate 
process,  especially  if  it  has  been  perpetuated  in  the 
strictest  traditions  over  time,  as  with  the  military. 
However,  the  consequence  of  not  transforming  the  structure  is 
the  perpetuation  of  ineffective,  redundant,  costly  systems  in 
an  era  cf  diitiinishing  resources.  Organizations  should  be 
configured  based  on  their  information  needs  and  how 
information  supports  their  overall  missions.  This  could 
result  in  an  alteration  of  the  organization's  culture. 
However,  if  a  change  is  warranted,  a  plan  must  be  developed 
within  the  fraiTiework  of  the  existing  culture,  identifying  any 
potential  cultural  risks.  [Ref.  13:  p.  15]  Since  corporate 
culture  represents  the  beliefs  and  values  of  its  leadership. 
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it  is  imperative  that  any  paradigm  shift  from  a  department  to 
functional  area  organizational  structure  be  initiated  by  top 
management.  Further,  the  shift  must  be  frequently  monitored 
and  post -impl ementat i on  criteria  established  to  prevent  the 
reduced  impact  of  change  over  time. 

It  is  unrealistic  for  management  and  staff  to  expect 
overnight  benefits  from  an  IS  architecture  (Figure  9).  The 
immediate  impact  of  change  will  be  reduced  efficiency  and 
effectiveness,  confusion  within  the  organization  and  an 
increase  in  staff  turnover.  [Ref.  19:  p.  8]  The  intermediate 
impact  is  the  increase  in  resources  expended  and  the  temporary 
erosion  of  the  organization's  value  system  as  "a  new  corporate 
equilibrium  is  reached."  [Ref.  19:  p.  8]  The  desired  long¬ 
term  effect  of  change  is  "on  efficiency  of  operations  (costs); 
effectiveness  of  products  or  services;  quantity  and  quality  of 
inf  orm.ation ;  and  corporate  culture/management  culture."  [Ref. 
19:  p.  8] 

The  human  element  must  be  managed  to  affect  a  cultural 
change  thereby  implementing  a  new  technology.  No  longer  is  it 
sufficient  to  identify  the  process  and  technology  needed  to 
increase  the  effectiveness  and  efficiency  of  a  business.  It 
IS  vital  that  the  members  of  the  organization  accept  and 
support  the  recommendations  for  implementation  to  achieve 
success . 
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C.  POLITICAL  CLIMATE 


An  information  systems  architecture  is  not  so  dependent  on 
the  importance  cf  its  ideas  and  principles  as  it  is  on  the 
charisma  and  the  credibility  of  its  leadership.  Currently, 
the  CIM  initiative,  and  more  specifically  Paul  Strassman,  is 
the  driving  force  behind  all  DOD  IRM  and  ADP  issues.  New 
developments  and  modernizations  have  been  curtailed  and  the 
entire  Department  of  Defense  is  in  a  state  of  flux  waiting  for 
firm  policy  decisions  and  mandates,  as  well  as  product 
selection.  Buzzwords  depicting  CIM's  direction  change 
frequently.  Current  buzzwords  include  re-engineering, 
reusable  code  and  benchmarking.  Two  concepts  that  have  had 
decisive  political  impact  on  information  technology  (IT) 
within  DOD  are  TQM  and,  most  recently,  IDEF, 

1  .  TQM 

Total  Quality  Management  (TQM)  became  a  military,  and 
political,  concept  in  1990.  It  is  an  approach  to  changing 
management  practices  which  have  been  in  effect  for  decades. 
"TQM  IS  a  management  philosophy  and  approach  that  brings 
together  a  complete  set  of  management  principles  and 
techniques  for  an  organization  to  survive  and  grow  in  the 
1990's"  [Ref.  20:  p.  7-lj  IS/IT  efforts  are  required  to  be 
aligned  with  TQM.  IT  supports  TQM  as  a  "holistic  management 
approach" ; 
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•  Considers  the  total  system  (i.e.,  all  management  processes 
and  their  inter faces )... al 1  of  the  components  within  a 
system  and  the  people  that  work  in  it  must  work  toward  the 
aim  of  the  organization. 

•  Employs  a  complete  set  of  hard  (engineering)  and  soft 
(personnel)  management  sciences.  Leadership  behavior  must 
be  fine-tuned  to  energize  each  unique  individual  to  think 
and  work  toward  his  or  her  potential.  Team  efforts  should 
be  expected  to  produce  results  that  are  greater  than  the 
sum  of  the  individual  parts. 

•  Involves  and  benefits  managers,  employees,  customers,  and 
suppliers.  [Ref.  20:  p.  5-1] 


The  impact  of  IT  on  TQM  is  that  it  provides  the  means  for 
determining  what  processes  need  improving  and  the  analytical 
tools  to  complete  the  task.  TQM  is  designed  to  force  the  flow 
of  information  both  up  and  down  the  chain  of  command,  while 
assuring  consistency  and  accuracy  of  meaningful  and  shared 
data. 


The  combination  of  IT  and  TQM  promises  to  give 
organizations  a  definitive  strategic  advantage  (Figure  10). 
The  precepts  of  TQM  coupled  with  those  of  CIM  require  senior 
officials  and  IS/IT  teams  to  possess  the  political  savvy  to 
ensure  all  specifications  have  been  suitably  addressed  and 
documented . 

2.  IDEF 

Integrated  Definition  (IDEF)  language  is  the  latest 
methodology  to  be  selected  by  CIM  for  DOD  implementation.  An 
extensive  training  effort  is  currently  underway  to  educate 
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senior  IS  executives  and  functional  managers,  including  the 

members  of  the  CIM  executive  groups. 

IDEF  also  presents  managers  with  choices  that  they  would 
not  even  consider  using  other  methods,  including 
completely  eliminating  the  process  or  activity,  revamping 
procedures  or  the  judicious  application  of  information 
technology  to  help  solve  the  problem.  [Ref.  21:  p.  10] 

Developed  by  the  Army  Corps  of  Engineers,  IDEF  is  a  process 

driven,  planning  methodology  that  provides  a  framework  for 

building  an  IS  architecture. 

The  Navy  is  currently  evaluating  IDEF  for  use  service¬ 
wide.  The  Naval  Information  Systems  Management  Center  (NISMC) 
is  evaluating  seven  IS  project  proposals  submitted  by  the  Navy 
IDEF  Workgroup .  These  projects  consist  of  information  systems 
from  various  commands.  NISMC  will  select  prototype  projects 
which  will  commence  in  April  1992  and  must  be  scoped  to  ensure 
comp'letion  in  120  days.  These  projects  will  determine  the 
strengths  and  weaknesses  of  IDEF  and  ascertain  if  IDEF 
toolsets  are  user-friendly  as  well  as  the  level  of  expertise 
required  to  use  themi.  The  recommendations  made  to  NISMC  will 
be  valuable  in  determining  IDEF's  future  role  within  the  Navy. 

3.  Other  Efforts 

As  illustrated  by  IDEF,  there  is  a  concerted  effort 
underway  by  the  services  to  cooperate  with  the  CIM  initiative. 
Each  service  is  feverishly  working  to  develop  or  evaluate  the 
one  architecture  that  will  become  the  standard.  What  must  be 
understood  is  that  there  may  not  be  "one"  single  methodology 
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that  can  be  applied  to  each  service  or  even  to  each  department 
within  the  services.  Sufficient  room  for  interpretation  must 
be  allowed  for  the  adaptation  and  manipulation  of 
methodologies  within  specific  organizational  cultures. 
Another  political  barrier  is  the  issue  of  ownership.  Intra- 
and  inter-service  power  plays  can  seriously  hinder 
implementation.  If  one  methodology  produced  by  a  service, 
major  command  or  department,  is  forced  on  other  agencies,  the 
natural,  human  nature  response  of  rivalry,  resentment  and 
resistance  can  hamper  implementation, 
a.  NAMO  effort 

Several  IS  architecture  efforts  are  currently 
underway  in  the  Department  of  Navy.  For  NAVAIR,  the  Naval 
Aviation  Maintenance  Office  (NAMO)  has  been  chartered  to 
develop  a  prototype  Information  Strategy  Plan  (ISP)  and  a  Data 
Administration  ( Df. )  Program  for  aviation  logistics.  This 
effort,  initiated  approximately  one  year  ago,  has  been 
severely  hindered  by  politics  in  the  following  ways: 


1.  Scope:  Broadly  defined,  the  data  collected  for  the  DA 
program  has  grown  exponentially.  Difficulty  now  exist 
now  in  how  to  utilize  all  the  information  gathered. 

2.  Personnel:  There  are  only  six  members  assigned  to  the 

NAMO  project,  none  of  whom  is  full  time.  Other 
activities  have  taken  precedence  over  the  ISP  and  DA 
resulting  in  a  four  month  suspension  until  April  1992. 

3.  CIM:  The  requirements  and  directives  for  CIM  frequently 
conflict  with  methods  already  in  progress  requiring 
IS/IRM  divisions  to  be  increasingly  flexible. 
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4.  Cooperation.  Significant  collaboration  is  required 
between  NAMO,  NAVAIR,  and  other  DON  agencies.  Dissension 
has  been  expressed  by  others  regarding  NAMO ' s  choice  of 
methodology  (James  Martin's  IE),  case  tool,  and  the  scope 
of  the  project  being  too  unique  to  aviation  logistics. 
However,  the  NAMO  team  has  received  support  from  senior 
officials  which  enhances  their  credibility. 

Politics  are  inherent  to  the  government  and  the  military. 
Credibility,  seniority  and  authority  all  profoundly  affect 
political  decisions.  Moreover,  with  the  high  rate  of  turnover 
built  into  the  services,  what  is  important  to  one  commanding 
officer  01  director  may  be  superseded  by  the  new  goals  and 
objectives  of  his/her  relief  or  by  those  of  a  new  boss.  One 
senior  official  may  envision  IS  architectures  as  critical, 
whereas  another  may  determine  the  installation  of  a  local  area 
network  (LAN)  to  be  mission  essential.  Both  deal  with  IRM 
issues,  but  if  instituted  imprudently,  they  can  severely 
thwart  projects  already  in  progress. 

D.  SENIOR  MANAGEMENT  INVOLVEMENT 

Underlying  ail  of  the  challenges  to  implementation  is  the 
degree  of  involvem.ent  by  senior  officials.  Senior  management 
IS  the  catalyst  for  the  entire  effort.  Top  management  must 
allocate  sufficient  resources,  people,  funding,  necessary 
tools  and  hardware,  for  an  IS  architecture  to  be  successfully 
imp  1 ement  ed . 

Senior  management  must  ensure  there  is  a  balanced  data 
administration  (DA)/IRM  strategy  (Figure  11).  The  short- 
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term/tactical  benefits  must  be  assessed  prior  to  addressing 
long-term/strategic  projects.  Data  is  standardized  through 
the  use  of  data  dictionary  tools,  which  then  becomes  the 
backbone  for  all  architectures  and  maintenance  support. 
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Figure  11:  A  Balanced  DA/IRy  Strategy 

Frequently,  data  standards  have  been  the  primary  focus  of  IRW 
plans  resulting  in  a  too  limited  scope.  Here,  data  is  coupled 
to  business  uses  as  end-users  are  given  access  to  appropriate 
existing  sources  cr  information  (i.e.,  archives,  files, 
screens,  etc.)  prirriarily  supporting  operation,  but  also 
decision  support,  areas. 

Once  the  tactical  aspects  are  underway,  the  strategic 
elements  can  be  satisfied.  Development  support  is  established 
for  the  construction  of  a  data  architecture.  The  redevelopment 
of  standard  interfaces  and  models  is  conducted  based  on  the 
strategic  needs  of  the  organization.  Also  crucial  in  long¬ 
term  planning  is  the  re-engineering  of  organizational 
attitudes  toward  the  importance  of  information  through 
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education  and  top-down  planning.  Again,  the  pressure  for  a 
paradigm  shift  must  come  from  the  top  for  success  to  be 
achieved.  The  balance  between  the  tactical  and  strategic 
focus  for  DP  and  business  issues  provides  valuable  direction 
for  senior  management  involvement  in  guaranteeing  both  short- 
and  long-term  success. 

The  impact  top  management  involvement  has  on  IS 
development  is  illustrated  in  a  survey  conducted  of  thirty- 
three  firms  (Figure  12).  While  a  relatively  small  sample, 
this  survey  suggests  clear  guidelines  for  success  in  IS 
devel  opm.ent  .  Suggested  levels  of  involvement  by  the  senior 
official  are  depicted  in  Figure  13.  Although  not  an  accepted 
practice,  it  is  critical  that  the  senior  executive  insist  on 
the  development  of  a  long-range  IS  plan  and  ensure  it  is 
consistent  with  o r gam t a 1 1  cn  strategies.  The  senior 
official's  involvement  throughout  the  IS  effort  impresses  upon 
both  the  implementors  and  the  entire  organization  the 
importance  ana  pertinence  of  the  pic3ect. 

Tw  gain  top  rr.anagement  support  at  the  outset.  NAVAIR's  I RM 
division  must  make  it  clear  that  the  purpose  of  the  IS  plan  is 
tc  dem.cnstrate  to  managemient  that  they  understand  the 
organization  and  possess-  a  sound  basis  for  documenting  and 
d<'velapi:ig  information  systemis.  [Ref.  6:  p.  18j  Fur  t  he  r  Ctor  e  , 
the  team  should  point  out  that  the  IS  architecture  effort  will 
r*-::.h.  1 1.  i  t':,  ir. tended  and  um.ntended  benefits  to  management. 


Firms  with 

Firms  with 

Unsuccessful 

Successful 

Yes  to: 

IS  Development 

IS  Development 

Executive  Steering  Committee 

23.1% 

55.0% 

Do  you  have  a  system  policy  committee, 
comprised  of  managers  from  functional  areas  of 
the  organization,  involved  in  setting  priorities 
and/or  allocating  resources  for  systems 
development? 

Written  Plans  23.1%  60.0% 

Do  you  have  a  written  overall  plan  for  systems 
development  which  (1)  covers  all  major 
functional  areas  of  the  business,  and  (2)  clariries 
inter-relationships  between  applications  (systems)? 

Development  Priorities  46.2%  90.0% 

Do  you  and  higher  level  management  have  a 
mutually  agreed  upon  set  of  criteria  for  deciding 
which  applications  (systems)  to  implement  first? 

Funding  Committee  38.5%  70  0% 

Has  top  management  made  a  long-term 
commitment  to  provide  stable  funding  for  system 
development  activity? 


Figure  12.  Results  of  Application  Development  Survey  [Ref. 

21:  p.  311] 


Activity 

Approve 

Insist 

Review 

Delegate 

Long-range  IS  plan 

X 

X 

Deferminitation  of  application  portfolio 

X 

CEO  decision  support  system 
specification 

X 

IS  budget  and  resource  allocation 

X 

Secunty/backup  plan 

X 

IS  mission  statement 

X 

•  •  '  . . .  1 

Selection  of  IS  executive 

X 

Technological  risk  assessment 

X 

X 

De.-.'En  of  systems 

X 

Hardware/soflware  selection 

X 

P •  312] 


Figure  15. 


CEO  Involvement  Levels  [.Ref. 


Intended  benefits  include: 


•  Information  is  managed  as  a  strategic  corporate  resource. 

•  System  priorities  can  be  more  comprehensively  understood. 

•  Functional  redundancy  can  be  identified. 

•  Systems  development  will  be  more  cost-effective.  [Ref.  6: 
P.  17] 

Some  additional  benefits  are: 

•  Data  administration  functions  are  reviewed  in  order  to 
capitalize  on  the  benefits  of  data  reusability  ana  shared 
integrated  systems. 

•  Healthy  cross-education  between  users  and  MIS  personnel 
may  occur,  indirectly  reducing  systems  design  errors. 

•  Cooperation  between  different  parts  of  the  company  that 
perform,  sim,ilar  function  may  increase.  [Ref.  6:  p.  17] 

An  IS  architecture  provides  a  vehicle  to  manage  data  better 
and  to  develop  more  cost  efficient,  effective  systems  that  add 
value  to  the  organization.  The  IRM  division  must  impress  on 
mianagement  the  realization  that  any  improvements  generated  by 
the  effort  directly  correspond  to  the  organization  achieving 
its  business  objectives. 

Senior  management  support  is  essential  to  implementation 
of  an  IS  effort.  Top  managemient  which  is  either  too  involved 
or  too  comiplacer.t  can  adversely  affect  implementation.  They 
must  be  able  to  determiine  what  is  best  for  the  organization 
and  its  culture  while  complying  with  the  existing  political 
envi r  onment . 
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V.  RECOMMENDATIONS 


The  Naval  Air  Systems  Command  needs  an  organization-wide 
information  systems  architecture.  The  many  architecture 
efforts  which  are  currently  in  progress  should  be  suspended 
and  a  comprehensive  evaluation  of  IS/IRM  accomplishments 
should  be  examined.  Viable  portions  and/or  successful 
projects  should  be  selected  for  possible  adaptation  for  a 
command-wide  architecture.  This  suspension  is  critical  for 
NAVAIR  headquarter's  to  gain  management  control  of  information 
resources,  as  well  as  to  enforce  standardization  throughout 
the  organization. 

The  IRM  division,  AIR-713,  must  evaluate  Enterprise 
Architecture  Planning  to  determine  its  feasibility  as  a 
methodology  for  the  organization.  It  is  recommended  that 
initially  consultants  be  retained  to  provide  preliminary 
guidance  and  training.  Once  EAP  has  been  officially  accepted, 
preparatory  training  programs  should  be  developed  and 
instituted  throughout  the  organization.  To  gain  commitment 
and  cooperation,  training  must  begin  with  headquarters  and 
senior  management,  and  filter  down. 

The  pro3ect  must  conrunnence  as  a  top-down  planning  approach. 
It  is  vitally  important  to  the  success  of  this  effort  that  the 
team  include  business  and  systems  personnel  and  management  and 
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users  from  field  commands.  This  is  essential  for  ownership  to 
be  gained  at  the  outset.  These  persons  are  best  identified 
during  the  initial  training  sessions.  Understanding  the 
vastness  of  NAVAIR,  tele-  and  video-conferencing  should  be 
utilized  whenever  possible  to  minimize  the  impact  on  funding. 
Electronic  mail  (E-mail)  can  also  serve  to  optimize  currently 
available  IT. 

As  the  team  and  project  progress,  the  reorganization  or 
redesignation  of  functional  areas  with  NAVAIR  will  become 
apparent.  The  organization's  culture  must  be  accurately 
identified  and  planned  for  this  to  be  successful.  Again, 
outside  consultants  may  be  useful  and  worth  the  expense  to 
ensure  that  strategy  is  developed  correctly  and  satisfies  the 
needs  of  the  organization. 

EAP  can  be  easily  adapted  to  any  requirements, 
methodology,  or  tools  selected  under  CIM.  IDEF  corresponds 
well  to  level  I  and  II  of  EAP.  To  gain  the  strategic 
advantage,  however,  the  last  two  levels  must  be  performed. 
The  architecture  and  implementation  phases  confirm  that  data 
has  been  properly  documented  and  that  systems  and  applications 
created  will  meet  organizational  requirements  and  can  be 
integrated . 

As  DOD  awaits  CIM  selection  of  a  standard  toolset, 
specifically  I-CASE,  it  is  not  suggested  that  new  tools  be 
purchased.  Several  toolsets  are  already  in  use  within  NAVAIR. 
Texas  Instrument's  Information  Engineering  Facility  (lEF)  has 
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been  widely  used  by  NAVAIR  and  is  recommended  for  continuation 
until  the  standard  tool  is  promulgated.  lEF  is  a  fully 
integrated  CASE  product  that  supports  the  entire  life  cycle. 
The  current  lEF  environment  is  included  in  Appendix  A. 
Upgrades  to  existing  software  are  more  economically  feasible 
at  this  time. 

The  use  of  Enterprise  Architecture  Planning  and  the  tools 
and  resources  currently  available  will  enable  NAVAIR  to 
achieve  the  long-term  goals  of  improved  productivity, 
efficiency,  effectiveness  and  quality  while  reducing  costs. 
The  decision  making  process  will  be  greatly  enhanced  providing 
better  utilization  of  resources.  EAP  will  allow  NAVAIR  to 
adapt  quickly  to  the  rapidly  changing  CIM  environment. 

The  savings  promised  by  CIM  are  overestimated.  The 
developnient  of  an  IS  architecture,  the  consolidation  of 
systems  and  departments,  coupled  with  the  reduction  of 
personnel,  will  require  significant  up-front  dollars  and 
resources.  However,  the  CIM  mandate  is  permanent.  NAVAIR 
must  work  to  adhere  to  its  precepts  and  directives  to  ensure 
that  reductions  in  resources  do  not  adversely  affect  the 
organization's  military  mission.  A  comprehensive,  command¬ 
wide  information  systems  architecture  will  provide  the  best 
mechanism  for  achieving  that  objective. 


68 


A.  FOLLOW-ON  STUDY  AREAS 


The  following  is  a  list  of  areas  which  would  be  beneficial 
in  assisting  NAVAIR  with  an  IS  architecture: 

•  A  case  study  of  one  or  more  organizations,  non-profit 
and/or  of  similar  size,  which  have  successfully  completed 
and  implemented  an  information  systems  architecture. 

•  A  case  study  of  the  organizational  culture  of  NAVAIR.  This 
would  be  of  great  importance  to  the  IS  effort  as  well  as 
save  considerable  time. 

•  Provide  overviews  of  tools  chosen  and  supply  critical 
cost/benefit  analysis  for  systems  and  technology. 

The  Naval  Air  Systems  Command  IRM  division  is  actively 
pursuing  solutions  to  its  information  systems  architecture 
requirements.  High-level  discussions  are  in  progress  to 
evaluate  viable  options.  Several  significant  architecture 
pro]ects  are  underway  but  are  of  limited  scope.  NAVAIR  must 
develop  a  commar.o-wide  architecture  to  identify  and  eliminate 
redundancy  and  tc  produce  more  cost-effective  systems  that 
meet  the  needs  of  the  organization.  The  proposed 

compi ehens 1 ve  effort  will  prov:de  NAVAIR  with  a  strategic 
advantage  in  an  era  of  diminishing  resources. 
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APPENDIX  A 


[Ref .  23 :  p .  6] 

Texas  Instrument's  lEF  Environment  for  DP/MIS  Applications 

A.  Life  Cycle  Phases  Supported: 

1.  Program  Management 

2.  Method  Management 

3.  Strategic  Systems  Planning 

4.  Analysis 

5 .  Design 

6.  Cede  (Application)  Generator 

7.  Configuation  Management 
S.  Reve r se/Re-Engineering 

B.  Methods  Supported: 

1.  Information  Engineering 

C.  Languages  Supported  for  Applications: 

1  .  C  o  b  0  1 

D.  DBMS  Supported  for  Application: 

1  .  DE2 

E.  P 1  a t f orms/Oper at ing  Systems  for  Development: 

1 .  IBM  MVS 

:  .  TSO 

3.  ISPF 

4.  T:  Bus  Fro 
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5.  IBM  PS/2 


»  6.  PC-AT 

F.  Price: 

1.  approx.  $200K  + 

G.  Representative  Data  Dictionary/Repository  Tools: 

1.  Integrated  main-frame  based  repository. 

2.  Supports  IBM's  Repository  Manager. 

H.  Future  Phase  and  Method  Support: 

1.  Ada  Code  Generator 

2.  Object  Oriented  Analysis 

3.  Open  Application  Systems 
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